<HTML>
<CENTER><A HREF = "http://lammps.sandia.gov">LAMMPS WWW Site</A> - <A HREF = "Manual.html">LAMMPS Documentation</A> - <A HREF = "Section_commands.html#comm">LAMMPS Commands</A> 
</CENTER>






<HR>

<H3>fix shake command 
</H3>
<H3>fix shake/cuda command 
</H3>
<P><B>Syntax:</B>
</P>
<PRE>fix ID group-ID shake tol iter N keyword values ... 
</PRE>
<UL><LI>ID, group-ID are documented in <A HREF = "fix.html">fix</A> command 

<LI>shake = style name of this fix command 

<LI>tol = accuracy tolerance of SHAKE solution 

<LI>iter = max # of iterations in each SHAKE solution 

<LI>N = print SHAKE statistics every this many timesteps (0 = never) 

<LI>one or more keyword/value pairs are appended 

<LI>keyword = <I>b</I> or <I>a</I> or <I>t</I> or <I>m</I> 

<PRE>  <I>b</I> values = one or more bond types
  <I>a</I> values = one or more angle types
  <I>t</I> values = one or more atom types
  <I>m</I> value = one or more mass values 
</PRE>

</UL>
<P><B>Examples:</B>
</P>
<PRE>fix 1 sub shake 0.0001 20 10 b 4 19 a 3 5 2
fix 1 sub shake 0.0001 20 10 t 5 6 m 1.0 a 31 
</PRE>
<P><B>Description:</B>
</P>
<P>Apply bond and angle constraints to specified bonds and angles in the
simulation.  This typically enables a longer timestep.
</P>
<P>Each timestep the specified bonds and angles are reset to their
equilibrium lengths and angular values via the well-known SHAKE
algorithm.  This is done by applying an additional constraint force so
that the new positions preserve the desired atom separations.  The
equations for the additional force are solved via an iterative method
that typically converges to an accurate solution in a few iterations.
The desired tolerance (e.g. 1.0e-4 = 1 part in 10000) and maximum # of
iterations are specified as arguments.  Setting the N argument will
print statistics to the screen and log file about regarding the
lengths of bonds and angles that are being constrained.  Small delta
values mean SHAKE is doing a good job.
</P>
<P>In LAMMPS, only small clusters of atoms can be constrained.  This is
so the constraint calculation for a cluster can be performed by a
single processor, to enable good parallel performance.  A cluster is
defined as a central atom connected to others in the cluster by
constrained bonds.  LAMMPS allows for the following kinds of clusters
to be constrained: one central atom bonded to 1 or 2 or 3 atoms, or
one central atom bonded to 2 others and the angle between the 3 atoms
also constrained.  This means water molecules or CH2 or CH3 groups may
be constrained, but not all the C-C backbone bonds of a long polymer
chain.
</P>
<P>The <I>b</I> keyword lists bond types that will be constrained.  The <I>t</I>
keyword lists atom types.  All bonds connected to an atom of the
specified type will be constrained.  The <I>m</I> keyword lists atom
masses.  All bonds connected to atoms of the specified masses will be
constrained (within a fudge factor of MASSDELTA specified in
fix_shake.cpp).  The <I>a</I> keyword lists angle types.  If both bonds in
the angle are constrained then the angle will also be constrained if
its type is in the list.
</P>
<P>For all keywords, a particular bond is only constrained if both atoms
in the bond are in the group specified with the SHAKE fix.
</P>
<P>The degrees-of-freedom removed by SHAKE bonds and angles are accounted
for in temperature and pressure computations.  Similarly, the SHAKE
contribution to the pressure of the system (virial) is also accounted
for.
</P>
<P>IMPORTANT NOTE: This command works by using the current forces on
atoms to caculate an additional constraint force which when added will
leave the atoms in positions that satisfy the SHAKE constraints
(e.g. bond length) after the next time integration step.  If you
define fixes (e.g. <A HREF = "fix_efield.html">fix efield</A>) that add additional
force to the atoms after fix shake operates, then this fix will not
take them into account and the time integration will typically not
satisfy the SHAKE constraints.  The solution for this is to make sure
that fix shake is defined in your input script after any other fixes
which add or change forces (to atoms that fix shake operates on).
</P>
<HR>

<P>Styles with a <I>cuda</I> suffix are functionally the same as the
corresponding style without the suffix.  They have been optimized to
run faster, depending on your available hardware, as discussed in
<A HREF = "Section_accelerate.html">Section_accelerate</A> of the manual.  The
accelerated styles take the same arguments and should produce the same
results, except for round-off and precision issues.
</P>
<P>These accelerated styles are part of the USER-CUDA package.  They are
only enabled if LAMMPS was built with that package.  See the <A HREF = "Section_start.html#start_3">Making
LAMMPS</A> section for more info.
</P>
<P>You can specify the accelerated styles explicitly in your input script
by including their suffix, or you can use the <A HREF = "Section_start.html#start_7">-suffix command-line
switch</A> when you invoke LAMMPS, or you can
use the <A HREF = "suffix.html">suffix</A> command in your input script.
</P>
<P>See <A HREF = "Section_accelerate.html">Section_accelerate</A> of the manual for
more instructions on how to use the accelerated styles effectively.
</P>
<HR>

<P><B>Restart, fix_modify, output, run start/stop, minimize info:</B>
</P>
<P>No information about this fix is written to <A HREF = "restart.html">binary restart
files</A>.  None of the <A HREF = "fix_modify.html">fix_modify</A> options
are relevant to this fix.  No global or per-atom quantities are stored
by this fix for access by various <A HREF = "Section_howto.html#howto_15">output
commands</A>.  No parameter of this fix can
be used with the <I>start/stop</I> keywords of the <A HREF = "run.html">run</A> command.
This fix is not invoked during <A HREF = "minimize.html">energy minimization</A>.
</P>
<P><B>Restrictions:</B>
</P>
<P>For computational efficiency, there can only be one shake fix defined
in a simulation.
</P>
<P>If you use a tolerance that is too large or a max-iteration count that
is too small, the constraints will not be enforced very strongly,
which can lead to poor energy conservation.  You can test for this in
your system by running a constant NVE simulation with a particular set
of SHAKE parameters and monitoring the energy versus time.
</P>
<P><B>Related commands:</B> none
</P>
<P><B>Default:</B> none
</P>
</HTML>
